How to achieve composability?

In systemsand software architecting, architecture can be viewed as a highlevel design that supports the construction of ICT-systems. Starting from a list of general requirements, the first part of this chapter gives an overview of the dimensions of such a design. In addition, the various, often contradicting, architectural views that are relevant for the various stakeholders are discussed. Special emphasis is given to the modeling of the system behavior and the dependability constraints. The second part of this chapter summarizes the requirements that binary components must fulfill in order to be composable in the context of dependable distributed real-time systems. Thereby, the emphasis is on timeliness and reliability. It is argued that in order to achieve composability, resource requirements and non-functional properties are of equal importance as functionality. In addition, the architectural styles that govern the interaction of components with their environment must be specified. A method for constructing the collective behavior of a set of components and achieving composability is sketched and demonstrated by means of an example. 2 Chapter 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002. 1. THE MANY ASPECTS OF AN ARCHITECTURE Architectures are increasingly used to guide the development and production of complex industrial ICT-products and to improve the related decision processes. Architectures play an important role in balancing the demands of the market and the customers, the technical solutions and the characteristics and capabilities of an organization as e.g. described in [8]. It is also recognized that different stakeholders (like development-, production and service engineers, development-, productand production managers, sales people and users/customers) have different needs and consequently use different views on an architecture. In the literature as well as in practice, there is, however, no commonly agreed view on these issues in terms of the definition of an architecture, the description and evaluation of an architecture and the architecting process. The main problems regarding the concept of an architecture can be summarized as follows: a) Current architectures are often developed in an ad-hoc way. As a consequence, the system development process is time-consuming and not flexible. b) Architectures are often developed for single systems and do not well support the variety associated with system families and product platforms. c) Architectures are often defined without giving enough attention to the product development process. In particular in the upper lifecycle phases of ICT-products, i.e. in the communication process with customers and users, the concept of an architecture is vague and ambiguous. d) Current architectures concentrate too much on one particular use (system-, hardwareand software design, system configuration, etc.) and do not support multiple consistent views that support the activities of the various stakeholders mentioned above. e) Present architectures concentrate too much on the structure of the system and do not adequately deal with the dynamic aspects, i.e. the behavior. The emphasis is on the modularization of the system and the definition of the interfaces. Even if the various interaction channels are modeled, there are no restrictions of the actual interaction patterns that can occur at runtime. f) There is not enough attention for the non-functional aspects of an architecture like dependability (performance, timeliness, reliability, availability, safety, security and robustness as defined in [21]) and other X-abilities (modularity, composability, scalability, maintainability, 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002.. Component-Based Architecting for Distributed Real-Time Systems 3 adaptability, extensibility, openness, interoperability, portability, reusability, etc.). Since we also miss adequate development methodologies that support the design of these system dimensions during all development phases, these considerations enter the construction of an ICT-system often only during the implementation phase. g) Current architectures do not support requirements tracing, i.e. they do not support a mechanism to document which architectural component, relation or constraint implements which requirement and vice versa. The same problem occurs for the tracing between the features of an architecture and their implementation. Section 1 of this chapter tries to identify the issues that are important for the development of an architecture and to define relevant research questions. The first two subsections deal with the definition and the purpose of an architecture. Subsection 1.3 introduces a number of general starting points for the design of an architecture and elaborates on the modeling of the behavior of ICT-systems. The relevant dimensions of an architecture are discussed in subsection 1.4. Subsection 1.5 identifies the most important stakeholders of an architecture and summarizes the corresponding architectural views and their relation with the various design dimensions. Section 2 discusses the requirements for achieving composability in Event-Triggered Architectures (ETA's). The emphasis is on dependable distributed real-time systems and especially on timeliness and reliability. In subsection 2.2, the extensions of the component interfaces necessary for achieving composability are described. Subsection 2.3 summarizes the development method underlying this discussion. Subsection 2.4 illustrates the proposed approach by means of an example. Finally, a number of conclusions are drawn and important directions for future research are indicated in section 3. 1.1 What is Architecture? The essence of architecting is the structuring of the construction and the behavior of an ICT-system. In this way the possible design alternatives are restricted and the various people involved in the design, production and maintenance of an ICT-system are supported in making sensible decisions. As in any design activity, also for defining architecture the key issues are balancing of the often contradictory requirements, compromising between extremes, and, of course, also elegance. 4 Chapter 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002. At the moment, there is no generally agreed definition of architecture. In the literature, various often very general descriptions can be found. Rechtin [26] e.g. defines an “overall system architecture” as the structure of a system, its functions and its environment together with the structure of the process by which it will be built and operated. Dewayne and Wolf [25] concentrate on software architectures and define them as a combination of elements, form and rationale. Elements can be processing-, dataor connecting elements. Form includes the importance of properties and relationships, the constraints on architectural elements and the constraints on the relations between architectural elements. Finally, the rationale gives motivations for the choice of a particular architectural style, the choice of the elements and the form. Bass et al. [1] define an architecture as "the structure or structures of the system, which comprise components, the externally visible properties of those components, and the relationship among them". An architecture can be considered as a common high-level model or design that supports the various disciplines and stakeholders in a) taking design decisions in a multi-dimensional design space, b) defining their designs in a multi-disciplinary environment and c) communicating their solutions. Note that not all parts of architecture need to be defined at the same level of abstraction. Usually the architecture can be considered as high-level design but parts like interfaces and protocols can even be defined at implementation level. Of course, the different parts of architecture should fit into one consistent framework. The level of abstraction of the architectural model depends on the level of detail at which the various activities of the early project phases have to be performed, e.g. on the envisaged degree of concurrent engineering. This chapter abstracts from the particular design or project to be supported by architecture. In addition, no distinction is made between systemsor software architecting. Already Dewayne and Wolf [25] consider an architecture as one step in the construction process of a system. Since the classical distinction between an implementation-independent conceptual model (defining the what) and an implementation model (defining the how) is obsolete, this construction process is not considered in terms of a classical waterfall model (e.g. requirements, architecture, specification, design and implementation) but as a continuous process of top-down refinement. This view is more consistent with the practice of e.g. object-based methodologies where components can be identified at various levels of refinement and every component consists of 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002.. Component-Based Architecting for Distributed Real-Time Systems 5 a specification and a design that identifies the sub-components and their relations. As already mentioned, most notions of an architecture concentrate too much on the structure of a design and do not adequately deal with its behavior. A typical example of this restricted view is given in an early paper of Shaw [30] that concentrates on abstract data types. Dewayne and Wolf [25] go one step further and distinguish between a process view that concentrates on the data flow through the processing elements, a data view whose emphasis is on the processing flow and the interdependence of processing and data upon the interconnections between the processors. This approach is very similar to the dataflow paradigm that can e.g. be found in SA/SD (Structured Analysis/Structured Design) and some object-oriented methods. Only recent definitions like the one given by Bass et al. [1] pay equal attention to structure and behavior. These authors define the architecture of a program or ICT-system as "the structure or structures of the system, which comprises software components, the externally visible properties of those components, and the relationships among them". Thereby, relationship refers to both the static interconnection between components by channels and the dynamic interaction. Unfortunately, this approach to architecting is still not widely used in industry. 1.2 What is Architecture Good for? The overall aim of architecture is the improvement of the quality of the ICT-system and its product development process. Key factors for the success of a project are the emphasis on the early development phases, the interdependence between product and process, and the interdisciplinary nature of decision-making by the architect(s) in cooperation with the various stakeholders. In particular, an architecture has the following important advantages: a) It establishes a framework for satisfying the requirements. b) It forms a technical basis for the subsequent refinement of the system. c) It restricts the design alternatives by enforcing a particular architectural style (e.g. a central or a distributed architecture, an event-driven or a time-driven architecture, etc.) and taking important design decisions. d) It supports requirements tracing, i.e. it provides a mechanism to document which architectural component, relation or constraint implements which requirement and vice versa. 6 Chapter 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002. e) In addition, it supports implementation tracing, i.e. the tracing between the features of an architecture and their implementation. f) It forms a basis for reducing risks by supporting the various activities that have to be performed during the early development phases. Among the most important are – An evaluation in order to ensure the consistency and quality of the architecture, – a feasibility study in order to make sure that a system can be made within the given constraints and – an assessment of the threats and risks a project is exposed to. g) It supports the answering of "what-if" questions that are e.g. related to different uses of the product and its future evolution. h) It forms not only a basis for designing a system but also for designing the related engineering-, production-, serviceand maintenance processes. i) It forms the managerial basis for cost estimation, project management and configuration management. In particular, an architecture should support – project planning, – concurrent engineering in general, – hardware/software codesign in particular, – configuration management during the development phase and – configuration selection and management with respect to the market and the customers. j) It forms an important basis for the reuse of components at the architectural level. k) It forms a common basis for the communication of the various stakeholders of a system. Since these persons very often do not share a common background or methodology, interdisciplinary decision making is a key issue. 1.3 Modeling the System Behavior As already mentioned, an architecture must be an integral part of the development methodology of an ICT-system. Such a development methodology should meet the following requirements [10]: 1. It should be based on uniform paradigms that can be used for the whole design trajectory from the modeling of the process to be supported by the system down to the implementation. 5 of Mehmet Aksit (ed.), Software Architectures and Component Technology, Kluwer 2002.. Component-Based Architecting for Distributed Real-Time Systems 7 2. Equal emphasis should be given to the modeling of the static and the dynamic structure of the system, i.e. the modeling of the components and their interfaces as well as the behavior. 3. It should support the specification and verification of non-functional constraints during all development phases. A visualization of the above requirements is shown in Figure 1: it gives an overall view of the five most important development steps of an ICTsystem together with the four most important architectural dimensions along which the system must be refined. The development steps (not necessarily of the project management phases) shown in Figure 1 are: a) the modeling of the process to be supported; b) the design of an architecture of the system that has to support the process; c) the design; and finally d) the implementation of the system. 1 Note that this process can either be a physical production process, an information providing process, a logistic process, a service process or the process of using a particular system. Structure Behavior Process Model